Service accounts

Non-login identities for CI/CD and automation. A service account is a real auth.users row authorized through ordinary user_grants, so RLS, user_roles() resolution, and role traversal work unchanged. It's addressed by a unique catalog name (e.g. acmeCo/ci-bot) that acts as a management anchor: holders of the new service-account capabilities on a covering prefix manage the account. The account's own access comes solely from its grants, which may span prefixes.

Schema: new internal.service_accounts table (unique catalog_name, SP-GiST-indexed for prefix scoping) and a refresh_tokens.created_by column recording the minting admin.

API keys are refresh tokens

There is no bespoke credential type. createApiKey mints a multi-use refresh token owned by the account and returns the bearer secret exactly once, in the base64 {id, secret} form that Authorization: Bearer and POST /api/v1/auth/token already accept. Revoking zeroes valid_for: the token becomes inert immediately (every request re-verifies against the database) while the row survives for audit. revokeAllApiKeys is the credential kill switch.

Service accounts cannot self-manage credentials: createRefreshToken / revokeRefreshToken reject service-account callers, so a leaked key can't mint its own replacements or revoke outside the admin flow. (A residual self-service surface exists via PostgREST's refresh_tokens grants; it disappears with PostgREST.)

Authorization

Four new fine-grained capabilities (QueryServiceAccounts, CreateServiceAccount, CreateApiKey, RevokeApiKey), bundled as manage_service_account and included in team_admin:

The per-prefix CreateGrant check on add is the anti-escalation guard: a manager can't hand an account reach they couldn't grant anyone. Removal has no per-prefix requirement since it only narrows access. Re-adding an existing grant overwrites its capability, so downgrades work in one call.

Also in this PR

• New Sensitive GraphQL scalar for one-time secrets: serializes as a string, redacting Debug, and distinct in the schema so client tooling can recognize and redact it. Applied to API-key, refresh-token, and Stripe setup-intent secrets.
• The bearer-credential auth path and POST /api/v1/auth/token now share one generate_access_token, so credential-error sanitization lives in one place.
• Stripe billing-contact selection excludes service accounts, whose synthetic @service_accounts.estuary.dev addresses must never become a tenant's billing contact.
• CI: the flaky Stripe integration test runs last so it can't skip later steps (it still gates the job).

Testing

sqlx tests cover the lifecycle end to end: create with multi-grant seeding, mint, list (including derived lastUsedAt), revoke and kill switches with idempotency, self-management rejection, duplicate catalog names, validFor validation, and grant add/remove/overwrite semantics. A second test verifies a team_admin holder without full Admin can manage accounts while CreateGrant still bounds escalation. The JWT-signing exchange path is covered by existing pgTAP tests.